home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98c.txt
/
000019_icon-group-sender _Mon Sep 14 08:22:30 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
2KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06186
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 14 Sep 1998 08:22:29 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA01505; Mon, 14 Sep 1998 08:22:02 -0700
Date: Fri, 11 Sep 1998 17:38:15 -0700
From: Gregg Townsend <gmt>
Message-Id: <9809120038.AA13184@hawk.CS.Arizona.EDU>
To: icon-group
Subject: Re: Unicode support or support for non-ASCII based character ma
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Using 16-bit characters in Jcon would be possible, and I don't think
it would necessarily incur a huge performance penalty. What's hard
is redesigning the Icon language to support Unicode. For example:
-- In Unicode, there aren't just 26 lower-case letters, and
they're not all contiguous. What should &lcase contain?
How would this affect existing programs?
-- How should output be handled? If a non-ASCII character is
written, should it be encoded in UTF8? What about existing
programs that write 8-bit ISO-Latin-1 characters and don't
expect any such encoding?
The design work is the hard part.
---------------------------------------------------------------------------
Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu
Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W
Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325
The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246